Parity stripe lock engine

ABSTRACT

Embodiments described herein include a PSL engine that includes various memory elements that permit the engine to grant locks on particular portions of data in a stripe in a RAID storage system. The PSL engine can assign (or lock) different blocks of the stripe for different operations. The PSL engine can grant locks to multiple operations for the same stripe if the operations access mutually exclusive blocks of the stripe. Each time a new operation is requested, the PSL engine determines whether the operation would affect a stripe data block that is currently assigned to another operation. If the new operation corresponds to a block of data in the stripe that includes data locked by another operation, the PSL engine assigns the new operation to a wait list. In one embodiment, the PSL engine maintains a wait list for each of the stripes in the RAID system.

BACKGROUND

The present invention relates to parity stripe locks, and morespecifically, to granular locking of sub-portions (or blocks) of thestripes.

Storage adapters for redundant array of independent disks (RAID)distribute client data across multiple disk drives in order to improveperformance and increase data redundancy. RAID levels greater than RAID0 provide protection against unrecoverable (sector) read errors, as wellas whole disk failure. In a RAID 5 or RAID 6 array, if a received writerequest is too small and cannot be combined with other writes to coverthe entire data region of a parity stripe, the write is performed as adelta update (also called a normal parity update). In doing so, the olddata is read to obtain a change mask or “delta” between the old and newdata. To complete the update, the parity drive(s) for the affectedstripe or stripes is updated using the change mask. When a large numberof requests are outstanding simultaneously, it is possible for tworequests to write data to different locations within a RAID stripe atthe same time which would touch the same parity. If allowed to proceed,the simultaneous writes may incorrectly update the parity data. Toprevent this, two operations which affect the same region of parity maynot be allowed to be performed at the same time. The enforcement of thisrule is upheld by a parity stripe lock (PSL).

SUMMARY

One embodiment of the present invention is a method that includesidentifying at least one entry in a first memory based on an IDassociated with a received operation, where the first memory contains afirst plurality of entries each storing a use-bit vector for one of aplurality of stripes in a RAID storage system, and where each use-bitvector stores individual bits that each indicate whether a block of datain one of the stripes is locked by an operation. Upon determining thatthe received operation collides with the use-bit vector in the at leastone entry in the first memory, the method includes storing the receivedoperation as a waiter operation in at least one entry in a secondmemory, where the second memory contains a second plurality of entrieseach storing information for a corresponding waiter operation that iswaiting to obtain a lock for at least one block of data in one of thestripes.

Another embodiment of the present invention is a RAID adapter thatincludes a first memory containing a first plurality of entries eachconfigured to store a use-bit vector for a stripe in a RAID storagesystem, where each use-bit vector stores individual bits that eachindicate whether a block of data in one of the stripes is locked by anoperation and a second memory containing a second plurality of entrieseach configured to store information for a waiter operation that iswaiting to obtain a lock for at least one block of data in one of thestripes. Moreover, the RAID adapter includes logic configured toidentify at least one entry in the first plurality of entries based onan ID associated with a received operation and, upon determining thatthe received operation collides with the use-bit vector in the at leastone entry in the first plurality of entries, store the receivedoperation as the waiter operation in at least one entry in the secondplurality of entries.

Another embodiment of the present invention is a computer programproduct for managing a RAID storage system and includes acomputer-readable storage medium having computer-readable program codeembodied therewith, the computer-readable program code executable by oneor more computer processors to identify at least one entry in a firstmemory based on an ID associated with a received operation, where thefirst memory contains a first plurality of entries each configured tostore a use-bit vector for a one of a plurality of stripes in the RAIDstorage system, and where each use-bit vector stores individual bitsthat each indicate whether a block of data in one of the stripes islocked by an operation. Upon determining that the received operationcollides with the use-bit vector in the at least one entry in the firstmemory, the program code is executable to store the received operationas a waiter operation in at least one entry in a second memory, wherethe second memory contains a second plurality of entries each configuredto store information for a corresponding waiter operation that iswaiting to obtain a lock for at least one block of data in one of thestripes.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 illustrates a computing system with a RAID storage subsystem,according to one embodiment described herein.

FIG. 2 illustrates a PSL engine, according to one embodiment describedherein.

FIG. 3 illustrates data types stored in a CAM of a PSL engine, accordingto one embodiment described herein.

FIG. 4 illustrates data types stored in a lock memory of a PSL engine,according to one embodiment described herein.

FIG. 5 illustrates data types stored in a user memory of a PSL engine,according to one embodiment described herein.

FIG. 6 is a method for granting locks using a PSL engine, according toone embodiment described herein.

FIG. 7 is a method for granting locks using a PSL engine, according toone embodiment described herein.

FIG. 8 is a method for releasing locks, according to one embodimentdescribed herein.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures. It is contemplated that elements disclosed in oneembodiment may be beneficially utilized on other embodiments withoutspecific recitation.

DETAILED DESCRIPTION

Embodiments described herein include a parity stripe lock (PSL) engineor module that includes various memory elements that permit the engineto grant locks on particular portions of data in a stripe (referred toherein as “blocks” or “blocks of data”). For example, a stripe mayinclude 256K bytes that spans multiple disk drives in a RAID storagesystem which can be subdivided into 64 4K blocks. As described herein,the PSL engine can assign (or lock) different blocks of the stripe fordifferent operations. For example, a first operation may affect only thefirst 10 4K blocks, while a second operation affects only the last 7 4Kblocks of the same stripe. Because these operations correspond todifferent (i.e., mutually exclusive) blocks in the stripe, the PSLengine can grant locks to both of these operations at the same time sothat the operations can be performed in parallel.

Each time a new operation is requested, the PSL engine determineswhether the operation would affect a block of data that is currentlyassigned to another operation. Stated differently, the PSL enginedetermines if the new operation affects data that has been locked byother operations. If the new operation affects different blocks of thesame stripe than the first and second operations, then these threeoperations can all be granted locks. Thus, any number of writeoperations can access the same stripe simultaneously so long as theseoperations affect mutually exclusive blocks in the stripe.

However, if the new operation corresponds to a block of data in thestripe that includes data locked by another operation, in oneembodiment, the PSL engine assigns the new operation to a wait list. Inone example, the PSL engine maintains a separate wait list for eachactive stripe (i.e., a stripe currently being accessed by an operation).Whenever a lock is released, the PSL engine can access the wait list tosee if the next operation can now be granted a lock. In one embodiment,the wait list is a first-in first-out (FIFO) list where the firstoperation in the list (i.e., the first waiter operation) must be granteda lock before the next waiters in the list are granted a lock.Furthermore, the PSL engine may permit the waiters to have locks formultiple stripes. For example, a waiter operation may affect data in twodifferent stripes, and as such, waits for two different locks—one foreach of the stripes. Only when the data in both the stripes is availabledoes the PSL engine grant the lock and allow the waiter to beginchanging the data in the two stripes.

FIG. 1 illustrates a computing system 100 with a RAID storage subsystem,according to one embodiment described herein. As shown, the system 100includes one or more computing devices 105, a RAID adapter 110, andstorage drives 120. The RAID adapter and storage drives 120 make up theRAID storage subsystem. The RAID adapter 110 serves as an intermediarybetween the computing devices 105 and the storage driver 120. Thecomputing devices 105 send read/write operations to the RAID adapter 110which then executes the operation on the storage drives 120 and returnsthe requested data (if any). To the perspective of the computing devices105, the plurality of drives 120 appear as one single drive when inreality they include multiple drives.

In this embodiment, the RAID adapter 110 stores user data received fromthe computing devices 105 across multiple storage devices 120. To do so,the storage drives 120 are logical divided by stripes which distributethe user data across the drivers 120. For example, portion A1 of drive120A, B1 of drive 120B, and P1 of parity driver 120P are all part of thesame stripe. Thus, when performing a write operation, the RAID adapter110 may store a portion in A1 on driver 120A and another portion ondrive 120B. This enables simultaneously reads where the data in the samestripe can be read from two drives 120 (i.e., drives 120A and 120B) inparallel. Moreover, to increase data redundancy, the system 100 includesthe parity drive 120P which stores parity data for each of the stripes.Like the user data, the parity data may be stored across multiple drivesrather than one drive (i.e., drive 120P) as shown here. If drive 120Afails and the data stored within it is lost, this data can be reproducedby performing a mathematical operation with the data in drive 120B andthe parity data in drive 120P. For example, the data stored at P1 in theparity drive 120P may be derived by XORing the data stored at A1 and B1in drives 120A and 120B. If drive 120A fails, the data stored at A1 canbe reproduced by XORing the data at B1 with the parity data P1. Althoughsystem 100 illustrates only one parity drive 120P, other RAID systemsmay include multiple parity drives that are calculated using differentparity operations (e.g., RAID 6). In addition, other RAID systems maydistribute the parity across multiple drives such that for an individualstripe, one drive may be the parity drive but for a different stripe adifferent drive may be the parity drive.

To manage data transfers between the compute device 105 and the storagedrives 120, the RAID adapter 110 includes a PSL engine 115 which grantsthe parity stripe locks mentioned above. Because it is possible for tworequests from the computing devices 105 to write data to differentlocations within a stripe at the same time, the simultaneous writes mayincorrectly update the parity data stored in parity drive 120P. Thelocks prevent this from occurring. When assigning locks, the PSL engine115 determines which portion of a stripe (and the corresponding paritydata) is affected by an operation. For example, the operation may notneed to access all the data in the stripe, but rather a sub-portion(i.e., a block). In one embodiment, the PSL engine 115 logically dividesthe stripe into different data blocks (e.g., a 256K stripe is dividedinto 64 4K blocks). So long as two write operations do not affectoverlapping data blocks, the PSL engine 115 can grant respective locksto the operations for different blocks of data in the same stripe. Thus,the two operations can access and change the parity data in parity drive120P in parallel since the operations affect different blocks.

FIG. 2 illustrates the PSL engine 115, according to one embodimentdescribed herein. As shown, PSL engine 115 includes acontent-addressable memory (CAM) 205, a lock memory 215, and user memory225. The CAM 205 stores a list of active stripes 210 in the RAID system.In one example, the active stripes 210 are the stripes that correspondto the inflight or active write operations or read operations whichrequire locks. For example, a RAID system may include millions ofindividual stripes but the CAM 205 may store only a portion of thosestripes (e.g., 2000 stripes) as the active stripes 210. As newoperations are received, the PSL engine 115 determines if the CAM 205includes empty entries—i.e., whether the CAM entries are less than thenumber of active stripes 210. If so, the PSL engine 115 adds the stripe(or stripes) corresponding to the operation to the active stripes 210.If not, the PSL engine 115 may leave the request on a separate workqueue (not shown).

Using CAM 205 to store the active stripes 210 permits the PSL engine 115to do a quick lookup (relative to using a random access memory (RAM)) todetermine if the engine 115 has previously granted any locks for aparticular stripe. For example, when receiving a new operation, the PSLengine 115 identifies a stripe identification (ID) associated with thenew operation which is then used to search the CAM 205. Because a CAMpermits each entry to be searched in parallel, the PSL engine 115 candetermine if the stripe is one of the active stripes 210 by performing asingle search rather than performing multiple searches as may berequired if a RAM was used to store the list of the active stripes 210.

The lock memory 215 stores the locked portions of the active stripes 220listed in CAM 205. In one embodiment, the number of entries in the CAM205 may be the same as the number of entries in the lock memory 215 sothat each entry in the CAM 205 has a one-to-one relationship with acorresponding entry in the lock memory 215. Each time a stripe ID isadded to the list of active stripes 210, the PSL engine 115 also adds anentry into the lock memory 215 which indicates which portions (i.e.,which blocks) of the stripe are locked. As described below, the lockportions of the active stripes 220 may be represented by a use-bitvector where each bit corresponds to a particular block in the stripe.Moreover, lock memory 215 may be implemented using a RAM or a CAM.

When a new operation is received, the PSL engine 115 may first check theCAM 205 to determine if the stripe ID contained in the operation is anactive stripe 210. If so, the PSL engine 115 then checks the lock memory215 to see which blocks in the active stripe 210 have been locked. Ifthen new operation is not requesting access to any of the locked blocks,the PSL engine 115 can then grant the lock and permit the operation toproceed. If, however, the operation wants to access a block in thestripe that is locked, the PSL engine 115 adds the operation to awaitlist.

User memory 225 includes a list of entries that form waitlists 230 forthe active stripes 210. Unlike the CAM 205 and lock memory 215 wheretheir entries may have a one-to-one correspondence (i.e., for everyentry in the CAM 205 there is a corresponding entry in the lock memory215), the user memory 225 may include different number of entries thanthe CAM 205 and lock memory 215. For example, the user memory 225 mayhave 1000 entries for storing the operations of the waitlists 230 whilethe CAM 205 and lock memory 215 include 2000 entries. However, thereverse may also be true where the user memory 225 includes more entriesfor storing waitlists 230 than the number of entries used to store theactive stripes 210 and the locked portions of the active stripes 220.

In one embodiment, the lock memory 215 stores pointers to entries in theuser memory 225. For example, the lock memory 215 may store a pointer toa first “waiter”—i.e., an operation waiting to get a lock for data inthe stripe—in the wait list 230 for a particular stripe. That way, bysearching lock memory 215, the PSL engine 115 can identify whether aparticular stripe has any waiters and where those waiters are stored inthe user memory 225. Moreover, in one embodiment, the waiters stored inthe waitlists 230 may be waiting on blocks of data in multiple stripesto become free. For example, a waiter may need access to data thatextends across multiple stripes. Before the waiter can be moved off thewaitlist 230 and executed, the PSL engine 115 may need to grant locks todata blocks within multiple stripes. That is, the PSL engine may need togrant two or more locks to the operation.

In one embodiment, the user memory 225 includes RAM—e.g., SRAM or DRAM.However, in other embodiments, the lock memory 215 and user memory 225may be other types of memory such as Flash memory.

FIG. 3 illustrates data types stored in the CAM 205 of the PSL engine,according to one embodiment described herein. As shown, each entry ofthe CAM 205 includes a valid bit 305, a redundancy group ID (RGID) 310,and a stripe ID 315. When a computing device sends a write operation tothe RAID adapter, the computing device may indicate the stripe ID 315within the request. Alternatively, the computing device may not know thestripe ID and instead the RAID adapter may identify the stripe IDassociated with a received operation based on other memory address dataincluded in the request. Regardless of how the stripe ID 315 is found,the PSL engine uses the ID 315 to search the CAM 205. Because each entryin the CAM 205 can be searched in parallel, the PSL engine only has tosearch the CAM 205 once to determine whether the stripe ID correspondingto the received operation matches one of the stripe IDs 315 alreadystored in the CAM 205. For example, the CAM 205 may output a bit vectorwith one bit for each entry in the CAM 205. A logical one represents amatching entry while a logical zero indicates no match.

The valid bit 305 indicates whether the CAM entry is valid or not. Thatis, when storing a new entry in the CAM 205, the PSL engine marks thebit 305 as valid. When removing an entry, the PSL engine marks the bit305 as invalid. In this way, the PSL engine can continuously add andremove entries in the CAMs. For example, if a write operation completesand the RAID adapter is no longer performing any write operations on aparticular stripe, the PSL engine may remove the stripe entry therebyfreeing the entry to store information about a different stripe.

The RGID 310 may be used to group stripes into a hierarchy. That is, theRAID system may include multiple drive arrays that use the same RAIDadapter. The different drives may be assigned to different redundancygroups, and thus, receive different RGIDs 310. Each redundancy group maybe assigned its own unique group of stripes. Thus, in one embodiment, aparticular stripe is identified using both the RGID 310 and stripe ID315. As such, the PSL engine may search the CAM using both of thesevalues in order to determine a match.

FIG. 4 illustrates data types stored in the lock memory 215 of the PSLengine, according to one embodiment described herein. Each entry of thelock memory 215 includes a use-bit vector 405, a RGID 410, a stripe ID415, a valid waiter bit 420, a first/second lock 425, a first waiterlink 430, a first/second lock 435, and a last waiter link 440. In oneembodiment, the PSL engine uses the result of indexing into the CAM 205using the stripe ID (and RGID if applicable) to identify one of theentries in lock memory 215. For example, the CAM 205 and lock memory 215may be part of the same CAM memory module where the bit vector returnedby the CAM 205 is used to select one of the entries in the lock memory215. That is, the PSL engine may store information in the CAM 205 andlock memory 215 such that the first entry in the CAM 205 corresponds tothe first entry in the lock memory 215, the second entry in the CAM 205corresponds to the second entry in the lock memory 215, and so forth.Alternatively, the CAM 205 and lock memory 215 may be separate memorymodules. In that case, the PSL engine includes logic for converting thebit vector outputted by performing the lookup in the CAM 205 todetermine a memory address pointing to one of the entries in the lockmemory 215. In this manner, the entries in the CAM 205 may have aone-to-one relationship with the entries in the lock memory 215 suchthat each entry in the CAM 205 corresponds to exactly one entry in thelock memory 215. To provide an example, the RGID 310 and stripe ID 315stored in the first entry of the CAM 205 may be the same RGID 410 andstripe ID 415 stored in the first entry in the lock memory 215. In oneembodiment, the RGID 410 and stripe ID 415 serve as a check for the PSLengine to ensure the look up was performed correct. That is, when usingthe bit vector outputted by the CAM 205 to index into the lock memory215, if the PSL engine determines the RGID 410 and stripe ID 415 do notmatch RGID and stripe ID used when indexing into the CAM 205, then PSLengine may determine the CAM 205 or the lock memory 215 has becomecorrupted.

The use-bit vector 405 includes a data bit for each block (orsub-portion) for the particular stripe indicated by the RGID 410 andstripe ID 415. For example, each stripe may contain 256K bytes of datawhich is logically divided into 64 4K blocks. Each of the 64 blocks isrepresented by a respective bit in the use-bit vector 405. For example,if the first bit in the vector 405 is a logical one, then the first 4Kblock of the stripe is currently locked—i.e., the RAID adapter iscurrently performing an operation that may affect the data stored inthis data block (or the parity data corresponding to the block). If,however, a bit in the use-bit vector 405 is a logical zero, thisindicates that the corresponding block of data is free—i.e., the PSL cangrant a lock for this block. Because a received operation may affectonly a portion of a stripe (i.e., a subset of the blocks in the stripe),the PSL engine can identify which blocks the operation affects, comparethose blocks to the use-bit vector 405, and determine whether therequested blocks are currently locked. If not, the PSL engine can assignthe lock to the operation and the operation can be performed—i.e., theRAID adapter can change or update the data stored at the block or itscorresponding parity data.

If any one of the blocks requested by the operation is currently locked,the PSL engine adds the operation to the waitlist for that stripe. Asshown, each stripe entry in the lock memory 215 includes a valid waiterbit 420 which indicates if there are any waiters for that stripe. Ifthere are not current waiters, then the waiter bit 420 may be a logicalzero, but if there are waiters, the waiter bit 420 is a logical one.Assuming the current operation is the first waiter, the PSL engine setsthe valid waiter bit 420 to a logical one and determines whether it isthe first or second lock for the operation. As mentioned above, eachoperation may request locks on multiple stripes (two in this example).The PSL engine sets the first/second lock bits 425 based on whether itis the first lock or second lock for the operation. The PSL engine addsthe operation into the user memory 225 shown in FIG. 5 and adds a link(or pointer) to that entry in the first waiter link 430 in the lockmemory 215. That is, the first waiter link 430 stores a pointer to thefirst waiter in the waitlist for the stripe. Similarly, the last waiterlink 440 stores a pointer to the last waiter in the waitlist for thestripe. In the case there is only one waiter for the stripe, both thefirst waiter link 430 and the last waiter link 440 point to the sameentry in the user memory 225. However, if there are multiple waiters,then the links 430, 440 point to different entries in the user memory225. Moreover, the entries in the lock memory 215 also includefirst/second lock bits 435 for the last waiter link 440. Like the bits425, the first/second lock bits 435 indicate whether the lock is thefirst lock or the second lock for the last waiter in the waitlist forthe stripe.

FIG. 5 illustrates data types stored in the user memory 225 of the PSLengine, according to one embodiment described herein. The entries in theuser memory 225 are added as additional waiters are identified by thePSL engine. Conversely, as blocks free up and waiters on the waitlistare granted locks, entries in the user memory 225 are removed.

As shown, each entry in the user memory 225 includes a valid bit 505, afirst/second lock 510, first lock next waiter link or pointer 515, avalid bit 520, a first/second lock 525, second lock next waiter link orpointer 530, number of locks 535, a starting block 540, an ending block545, and control data 550. As more waiters are added to the waitlist,the PSL engine updates the user memory 225 to create a linked list. Forexample, by evaluating the valid waiter bit 420 in the lock memory 215,the PSL engine identifies if there are any waiters for the stripe. Ifso, using the last waiter link 440, the PSL engine identifies the lastwaiter entry in the user memory 225. The PSL engine can add a new entryin the user memory 225 for the new waiter and update the last waiterlink 440 to point to the new entry. In addition, the PSL engine updatesthe last waiter entry in the user memory 225 to point to the new waiter(which is now the new last waiter). For example, if the entry in thelock memory 215 is the first lock for the last waiter (as indicated inthe first/lock bits 435), the PSL engine updates the first lock nextwaiter link 515 to point to the new waiter entry in the user memory 225.If the entry in the lock memory 215 is the second lock for the lastwaiter, then PSL engine updates the second lock next waiter link 530 topoint to the new waiter entry in the user memory 225. Similarly, the PSLengine updates the first/second lock bits 510 or the first/second lockbits 525 to indicate whether it is the first lock or the second lock forthe new waiter entry. Put differently, the first/second lock bits 510,525 tell the PSL engine whether the next waiter in the linked list isthe first lock next waiter link 515 or the second lock next waiter link530 in the subsequent entry in the user memory 225. Moreover, bypermitting each waiter (i.e., each operation) to have two locks, eachwaiter may be part of two separate linked lists. That is, the waiterstored at the first entry in the user memory 225 may be part of linkedlists (or wait lists) for the two different stripes represented by twodifferent entries in the lock memory 215. The first/second lock bits inthe lock memory 215 and user memory 225 keep the linked lists separate.

As an operation completes, the PSL engine determines whether the waiterson the waitlist can now be executed. To do so, the PSL engine uses thefirst waiter link 430 in the lock memory 405 to identify the firstwaiter for that stripe. Once the first waiter entry is identified in theuser memory 225, the PSL engine uses the starting block bits 540 and endblock bits 545 to determine whether the blocks in the stripe needed bythe first waiter are now free. That is, the PSL engine compares theblocks identified by the start and end bits 540, 545 to the use-bitvector 405 to ensure none of the request bits are still locked. If so,then the first waiter continues to wait. Moreover, in one embodiment,the PSL engine may not evaluate any other of the waiters in the waitlist for a stripe if the first waiter cannot be granted a lock. That is,the waiters in the same wait list are not permitted to cut to the frontof the wait list. Although this policy is not a requirement, doing somay prevent certain deadlocks and treat the operations fairly.

FIG. 6 is a method 600 for granting locks using a PSL engine, accordingto one embodiment described herein. Method 600 begins at block 605 wherethe PSL engine determines if there are entries available in memorybefore determining whether to process a received operation (e.g., awrite operation received by the RAID adapter from a computing device).For example, the PSL engine may determine whether there are a predefinednumber of free entries (e.g., at least two) in the CAM, lock memory, anduser memory before proceeding. If not, at block 610, the PSL engine mayleave the received operation on a work queues 610 until memory entriesbecome available.

Otherwise, at block 615 the PSL engine determines whether a stripe IDcorresponding to the received operation is already stored in the CAM.Moreover, in addition to using a stripe ID to search the CAM, the PSLengine may also use a RGID to search the CAM entries. If a matchingstripe ID is not in the CAM, at block 620 the PSL engine adds a newentry in the lock memory and the CAM. Referring to FIGS. 3 and 4, thePSL engine stores the RGID 310 and stripe ID 315 in a new entry in theCAM 205 and sets the bit 305 to indicate that the entry is valid. ThePSL engine also sets the use-bit vector 405 in the new entry in the lockmemory 215 to indicate which of the blocks of the stripe are locked bythe received operation. Thus, if a new operation is received that alsowants to access that stripe, the PSL engine can evaluate the use-bitvector 405 to determine whether the lock can be granted. Moreover, thePSL engine may store the same RGID and stripe ID information in the CAM205 in the RGID 410 and stripe ID 415 in the lock memory 215. Becausethe entry is new, the valid waiter 420 bits will indicate that there areno waiters for the stripe, and thus, the remaining fields in the entry(i.e., fields 425, 430, 435, and 440) are null.

If, however, the stripe ID is found in the CAM at block 615, the method600 proceeds to block 630. Put differently, if the stripe ID is found,then the PSL engine has previously granted a lock to at least oneoperation to access the data in the stripe—i.e., the stripe is active.At block 630, the PSL engine determines whether there are waiters in thelock memory. To do so, the PSL engine may use a bit vector outputted bythe CAM to identify a corresponding entry in the lock memory. Byevaluating the valid waiter bit 420, in the lock memory entry, the PSLengine determines whether there are any waiters for the stripe. Forexample, if the valid bit 420 is null, then there are no currentwaiters. However, if valid, then the PSL engine knows there is at leastone operation waiting to be assigned a lock for a block in the stripe.

If there are waiters, at block 650, the PSL engine adds a new entry touser memory which stores information about the current operation. Stateddifferently, the PSL engine creates a new waiter for the stripe byadding the operation currently being evaluated by the engine to thestripe's waitlist. Referring to FIG. 5, the PSL engine uses a free entryin the user memory 225 to create the new waiter operation. For example,the PSL engine indicates, using the valid bit 505, that the entry is nowbeing used (i.e., is no longer invalid) and stores information about theoperation in the subsequent bits of the entry. As shown in FIG. 5, thePSL engine may store the number of locks 535 the waiter is waiting onand the start 540 and end 545 blocks of the stripe for which the waiteris requesting a lock. If the waiter is requesting data across multiplestripes, then the start block 540 is the first block in the first stripeand the end block 545 is the last block in the last stripe. In thismanner, the start 540 and end 545 blocks define a chunk of contiguousmemory that may span one stripe or multiple stripes. In anotherembodiment, instead of using start 540 and end 545 blocks, the entriesin the user memory 225 may include one or more bit vectors to indicatewhich blocks of data are requested from the stripe or stripes. Thecontrol data 550 contains information which the PSL engine uses toexecute the operation corresponding to the waiter once the lock (orlocks) is granted.

At block 655, the PSL engine retrieves the last waiter informationstored in the lock memory 215 for the stripe that identifies the lastwaiter in the waitlist for a particular stripe. As shown in FIG. 4, eachentry in the lock memory 215 includes the last waiter link 440 whichpoints to an entry in the user memory that stores information about thelast waiter in the stripe's waitlist. Thus, using link 440, the PSLengine identifies the last waiter in the particular waitlist for theparticular stripe. Once the entry of the last waiter is identified inthe user memory, the PSL engine determines at block 660 whether thestripe is part of a first lock or a second lock for the last waiter.That is, because the last waiter can be part of waitlists for twodifferent stripes, the PSL engine determines if the particular stripebeing evaluated is the first lock or the second lock for the last waiterby evaluating the first/second lock bits 435 in the lock memory 215.Stated differently, the first/second lock bits 435 in the stripe entryin the lock memory 215 inform the PSL engine whether it should updatethe first lock data or the second lock data for the last waiter's entryin the user memory 225.

If the stripe is part of the first lock for the last waiter, method 600proceeds to block 665 where the PSL engine updates the first lock nextwaiter link 515 shown in FIG. 5 to point to the new waiter that wasadded the user memory 225 at block 650. As a result, the current lastwaiter now points to the new waiter that was just added. Putdifferently, the first lock next waiter link 515 in the last waiter(which is now no longer the last waiter in the waitlist) point to theentry of the new waiter in the user memory 225 added at block 650 (whichis now the new last waiter in the waitlist). Conversely, if the stripeis part of the second lock for the last waiter, at block 670 the PSLengine updates the second lock next waiter link 530 to point to the newlast waiter entry in the user memory 225. Furthermore, the PSL engineupdates either first/second lock bits 510 or first/second lock bits 525in the entry of the old last waiter to indicate whether the stripe ispart of the first lock or the second lock for the new last waiter addedat block 650. Doing so informs the PSL engine when traversing thewaitlist for a particular stripe using the entries in the user memory225 whether the stripe is part of a first lock or a second lock for thenext waiter in the list, and thus, whether to evaluate the first locknext waiter link 515 or the second lock next waiter link 530 whencontinuing to traverse the waitlist.

At block 675, the PSL engine updates the last waiter information storedin the lock memory. Because in blocks 650-670 the PSL engine added a newlast waiter in the user memory, the corresponding stripe entry in thelock memory is updated to point to the new last waiter. That is, thelast waiter link 440 is updated to point to the last waiter entry in theuser memory and the first/second lock bits 435 are changed to indicatewhether the stripe is part of a first lock request or a second lockrequest for the operation corresponding to the new last waiter.

Returning to block 630 of method 600, now assume that there are nowaiters for the current stripe being evaluated. At block 635, the PSLengine determines whether the use bits collide with the bits that arerequested by the operation. To do so, the PSL engine evaluates theuse-bit vector 405 stored in the stripe entry in lock memory 215 todetermine if the blocks indicated as being taken (or assigned) are alsobeing requested by the operation. For example, even though there are nowaiters for a stripe, there may already be a previous operation that hasobtained a lock on one or more blocks of data in the stripe which isreflected by the use-bit vector 405. Thus, if the current operationrequests a block of data that has already been assigned to anotheroperation in a previous lock request, the PSL engine determines that theuse bits collide—i.e., the current lock request cannot be granted. Ifthere is a collision (i.e., the already assigned blocks and the requestblocks overlap or are not mutually exclusive), method 600 proceeds toblock 640 where the PSL engine adds a new entry to the user memory. Thatis, the current operation becomes the first waiter for the stripe'swaitlist. At block 645, the PSL engine updates both the first waiterlink 430 and the last waiter link 440 in the stripe entry to point tothe new waiter entry in the user memory. The new waiter is the onlywaiter in the stripe's waitlist, and thus, the first waiter is also thelast waiter in the waitlist. Moreover, the PSL engine updates the firstand second lock bits 425 and 435 to indicate that whether the stripe ispart of a first lock request or a second lock request for the newwaiter.

After blocks 625, 645, or 675 is performed, the method 600 proceeds toblock 680 where the PSL engine determines if a second lock for thecurrent operation has been evaluated. Because each operation may requesta lock for multiple stripes (two in this example, but it could be threeor more), the PSL engine evaluates both lock requests. If the secondlock request has not yet been evaluated, the method 600 proceeds toblock 615 where the method 600 repeats. If, however, the PSL engine hasevaluated both lock requests (or only one lock was requested), at block685, the engine determines whether all locks for the operation currentlybeing evaluated are granted. For example, the PSL engine may determinethat the second lock request could have been granted but the operationmay be a waiter for its first lock request—i.e., the PSL enginegenerated a new waiter by adding the operation to a new entry in theuser memory. If all the locks cannot be granted, at block 690 the lockrequests continue to wait. For example, the PSL engine may complete thetwo lock requests once an operation that currently has a lock on data inthe stripe finishes, in which case, the PSL engine reevaluates therequests as discussed in FIG. 8.

If all the locks requests are granted (assuming that the operation hasmultiple requests), at block 695 the PSL engine completes the requestedaction. That is, the PSL engine grants the lock or locks and informs theRAID adapter that the operation is ready for execution. Referring toFIG. 1, the RAID adapter 110 can then perform the operation (e.g., awrite operation) by accessing and/or changing the data stored at theparticular blocks in the stripe or stripes in the drives 120.

FIG. 7 is a method 700 for granting locks using a PSL engine, accordingto one embodiment described herein. Method 700 includes several blocksthat where discussed above in FIG. 6, and thus, have been assigned thesame reference number. Since these blocks were discussed in detailabove, the function and logic performed when executing these blocks willnot be described here.

Method 700 begins at block 605 where the PSL engine determines if thereare entries available in memory before determining whether to process areceived operation (e.g., a write operation received by the RAID adapterfrom a computing device). If not, at block 610 the PSL engine leaves therequest on the work queue and method 700 ends. However, if there areavailable entries, at block 705 the PSL engine determines whether theoperation requests an immediate action. That is, in this embodiment, acomputing device can indicate that if the operation cannot be performedimmediately, the operation should be ignored—i.e., the operation shouldnot be added to a waitlist for a stripe. Thus, if the PSL enginedetermines that the requested lock or locks cannot be granted, the PSLengine fails the request and does not add the operation to a waitlist.

If the computing device has not requested that the operation beperformed immediately if possible rather than be added to a waitlist,method 700 proceeds to block 710 where the lock request is evaluatedusing the logic illustrated in blocks 615-695 of FIG. 6. Because theoperation can be added to a waitlist, the PSL engine performs the method600 as discussed above. However, if the computing device requests thatthe operation be performed immediately, at block 615 the PSL enginedetermines whether the stripe ID for the operation is stored in the CAM.If the stripe ID is found—i.e., there are other operations that havebeen granted locks to the stripe—at block 630 the PSL engine determineswhether there are waiters for the stripe by evaluating the stripe entryin the lock memory. If there are waiters, the PSL engine fails therequest at block 715 and ignores the operation. That is, because thereare already waiters for the stripe, the operation would need to be puton a waitlist before the PSL engine can grant the lock. However, sincethe computing device requested that the operation be performedimmediately (which the PSL engine cannot do), the engine fails therequest.

If there are no waiters, method 700 proceeds to block 635 where the PSLengine determines whether the use bits collide with the bits that arerequested by the operation. To do so, the PSL engine evaluates theuse-bit vector 405 stored in the stripe entry in lock memory 215 todetermine if the blocks that are indicated as being taken (or assigned)correspond to blocks being requested by the operation. If there is acollision, at block 715 the PSL engine fails the request since theoperation would need to be added to a waitlist.

If, however, the stripe ID was not found in the CAM (block 615) or thereis not a data collision (block 625), at block 680 the PSL enginedetermines whether both lock requests for the operation have beenevaluated using method 700 or if only one lock was requested. If not,the method 700 returns to block 615 to evaluate the second lock request.If so, method 700 proceeds to block 725 where the logic described inblocks 620, 625, and 695 is performed. The PSL engine would not need toperform block 680 since it has already determined that the second lockhas been evaluated at block 720. The PSL engine would also not need toperform block 685 as any locks that are not granted would have resultedin method 700 terminating at block 715.

FIG. 8 is a method 800 for releasing locks, according to one embodimentdescribed herein. Method 800 may begin after an operation has completedand the blocks that were previously locked by the operation can now befreed. At block 805, the PSL engine identifies the corresponding lockentries in the CAM and lock memory for the lock that was freed. At block810, the PSL engine clears the bits in the use-bit vector store in thelock memory entry corresponding to the freed up lock. For example, ifthe operation had a lock for the first four blocks in the stripe, thePSL engine changes the bits corresponding to these four blocks toindicate that the blocks are now free to be assigned to otheroperations. If a valid entry is not found in the CAM or the specifieduse bits are already cleared, the PSL engine flags this as an error andfails the request.

At block 815, the PSL engine determines if the stripe entry in the lockmemory 215 has waiters. Like in block 630 of FIG. 6, the PSL engineevaluates the valid waiter bit 420 in the lock memory entry to identifywhether there are any waiters for the stripe. For example, if the validbit 420 is null, then there are no current waiters. However, if valid,then the PSL engine knows there is at least one operation waiting to beassigned a lock for a block in the stripe.

If the stripe has waiters, at block 820, the PSL engine retrieves thefirst waiter information that is stored in the first waiter link 430 inthe entry of the lock memory 215. With this information, the PSL enginelocates the first waiter in user memory 225. Moreover, the PSL enginemay also identify the first/second lock bits 425 to determine which lockrequest the stripe is part of (assuming the first waiter has two lockrequests). Using the start 540 and end 545 blocks in the first waiterentry in the user memory 225, the PSL engine determines if the lockrequest can be granted. That is, at block 825, the PSL engine determinesif the use bits collide by referencing the use-bit vector 405 in thelock memory 215 to determine if the blocks requested by the first waiterare currently assigned to another operation.

If the blocks of the stripe requested by the first waiter are free, atblock 830 the PSL engine updates the use-bit vector 405 to indicate thatthose blocks are now assigned (i.e., are no longer free) and grants thelock to the first water. At block 835, the PSL engine updates the firstwaiter information stored in the first waiter link 430 in the stripeentry in the lock memory. In one embodiment, the PSL engine updates thefirst waiter link 430 to point to the next waiter—i.e., the secondwaiter in the waitlist for the stripe. If the first waiter was the lastwaiter—i.e., the waitlist only has one waiter—then the PSL engine may atblock 835 set the valid waiter bit 420 to indicate that there are nolonger waiters in the waitlist, thereby invalidating any data stored inthe first/second lock bits 425, first waiter link 430, first/second lock435, and last waiter link 440.

At block 840, the PSL engine determines if the waiting operationrequested two locks rather than just one lock and if only one of thoselocks is held. That is, the PSL engine determines if the waitingoperation requested locks to blocks that span two different stripes. Ifso, method 800 returns to block 815 to update the lock memory to releasethe second lock. However, if all the locks have been released, at block845 the PSL engine removes the entry in user memory corresponding to thefirst waiter. That is, now that the first waiter was granted the lock atblock 830 and is no longer on a waitlist for any stripe, the PSL engineremoves the first waiter's entry from the user memory. The engine may doso by updating the valid bit 505 to indicate that the entry is now free.This action invalidates the remaining data stored in the entry—i.e., thefirst/second lock bits 510, first lock next waiter link 515, etc. ThePSL engine may also delete the bits in the entry (i.e., change theirvalues to null).

At block 850, the waiting lock request is completed. That is, thewaiting operation has the lock or locks needed to access the data andcan execute. However, because other operations may be waiting, method800 returns to block 815 to determine if the lock entry being releasedhas other waiters.

At block 815, if the lock entry does not have waiters, method 800proceeds to block 855 where the PSL engine determines if the use-bitvector 405 is equal to zero. In one embodiment, the PSL enginedetermines if each bit of the use-bit vector 405 in the stripe entry iszero. If so, this means that no blocks in the stripe are currentlyassigned (or locked) to any operation. If at least one of the bits is alogical one, then at least one block in the stripe is locked.

Assuming the use-bit vector contains all zeros, at block 860, the PSLengine deletes the stripe entries in both the CAM 205 and lock memory215. Put differently, if the bits in the use-bit vector 405 are all zero(and there are no waiters), this means the operation currentlyrequesting the lock release is the last operation assigned a lock forthe stripe. Because no more operations want to access the data at thisstripe, the PSL engine can delete the stripe entries for that stripefrom the CAM 205 and the lock memory 215. Doing so may free up memory inthe CAM 205 and lock memory 215 so that a different stripe can be addedto these memories. For example, the operations that were left on thework queue at block 610 of FIG. 6 because there was not sufficientavailable entries in the CAM 205 and lock memory 215 may now be able tobe processed using method 600. Method 800 skips block 860 if at leastone of the bits in the use-bit vector 405 is non-zero—i.e., there is atleast one other operation with a lock to a block in the stripe. As such,the PSL engine keeps the stripe entry in the CAM 205 and lock memory215.

At block 865, the PSL engine determines whether the operation isrequesting a one lock release or a two lock release. If the PSL engineis currently performing the first pass (i.e., the first lock release) ofa two lock release, the method 800 returns to block 805 so the secondlock release of the two lock release can be performed. In addition toreaching block 865 from block 855 or 860, the PSL engine can reach block865 if the use bits collide at block 825. That is, if first waiter forthe stripe is requesting blocks that are still assigned to anotheroperation. In this example, the first waiter cannot be granted a lock atblock 830. The PSL engine does not evaluate whether the second waiter inthe waitlist for the stripe could be granted a lock. Put differently,the waitlist is a FIFO where the remaining waiters in the list must waitfor the first waiter (i.e., the head of the waitlist) to be granted alock before they can be granted locks to the stripe. Because the firstwaiter cannot be granted a lock, the first waiter continues to waituntil another operation releases a block for the stripe and the PSLengine can again see if the blocks requested by the first waiter collidewith the use-bit vector 405. Alternatively, method 800 may be modifiedso that if the use bits collide at block 825, the PSL engine evaluatesthe second waiter in the waitlist to determine if it can now be granteda lock—i.e., the request blocks do not collide with the use-bit vector405 for the stripe. In this embodiment, the waiters behind the firstwaiter can be granted a lock even if the first waiter cannot.

If the operation requests only one release or both locks have alreadybeen evaluated, at block 870, the PSL engine completes the lock releaseand may inform the RAID adapter that the release was performed. The RAIDadapter may inform the computing devices requesting the operations thatthey were performed successfully.

The descriptions of the various embodiments of the present inventionhave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to best explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdisclosed herein.

In the preceding, reference is made to embodiments presented in thisdisclosure. However, the scope of the present disclosure is not limitedto specific described embodiments. Instead, any combination of thefeatures and elements, whether related to different embodiments or not,is contemplated to implement and practice contemplated embodiments.Furthermore, although embodiments disclosed herein may achieveadvantages over other possible solutions or over the prior art, whetheror not a particular advantage is achieved by a given embodiment is notlimiting of the scope of the present disclosure. Thus, the aspects,features, embodiments and advantages are merely illustrative and are notconsidered elements or limitations of the appended claims except whereexplicitly recited in a claim(s). Likewise, reference to “the invention”shall not be construed as a generalization of any inventive subjectmatter disclosed herein and shall not be considered to be an element orlimitation of the appended claims except where explicitly recited in aclaim(s).

Aspects of the present invention may take the form of an entirelyhardware embodiment, an entirely software embodiment (includingfirmware, resident software, microcode, etc.) or an embodiment combiningsoftware and hardware aspects that may all generally be referred toherein as a “circuit,” “module” or “system.”

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

Embodiments of the invention may be provided to end users through acloud computing infrastructure. Cloud computing generally refers to theprovision of scalable computing resources as a service over a network.More formally, cloud computing may be defined as a computing capabilitythat provides an abstraction between the computing resource and itsunderlying technical architecture (e.g., servers, storage, networks),enabling convenient, on-demand network access to a shared pool ofconfigurable computing resources that can be rapidly provisioned andreleased with minimal management effort or service provider interaction.Thus, cloud computing allows a user to access virtual computingresources (e.g., storage, data, applications, and even completevirtualized computing systems) in “the cloud,” without regard for theunderlying physical systems (or locations of those systems) used toprovide the computing resources.

Typically, cloud computing resources are provided to a user on apay-per-use basis, where users are charged only for the computingresources actually used (e.g. an amount of storage space consumed by auser or a number of virtualized systems instantiated by the user). Auser can access any of the resources that reside in the cloud at anytime, and from anywhere across the Internet. In context of the presentinvention, a user may access applications (e.g., web services, datastorage services, and the like) or related data available in the cloud.For example, the PSL engine and RAID adaptor could execute on acomputing system in the cloud and to store client data. In such a case,the PSL engine could receive request (i.e., operations) from users(e.g., computing device 105) and store/retrieve data at drives 120located in the cloud. Doing so allows a user to access this informationfrom any computing system attached to a network connected to the cloud(e.g., the Internet).

While the foregoing is directed to embodiments of the present invention,other and further embodiments of the invention may be devised withoutdeparting from the basic scope thereof, and the scope thereof isdetermined by the claims that follow.

1.-7. (canceled)
 8. A redundant array of independent disks (RAID)adapter, comprising: a first memory containing a first plurality ofentries each configured to store a use-bit vector for a stripe in a RAIDstorage system, wherein each use-bit vector stores individual bits thateach indicate whether a block of data in one of the stripes is locked byan operation; a second memory containing a second plurality of entrieseach configured to store information for a waiter operation that iswaiting to obtain a lock for at least one block of data in one of thestripes; and logic configured to: identify at least one entry in thefirst plurality of entries based on an ID associated with a receivedoperation, and upon determining that the received operation collideswith the use-bit vector in the at least one entry in the first pluralityof entries, store the received operation as the waiter operation in atleast one entry in the second plurality of entries.
 9. The RAID adapterof claim 8, further comprising: a content addressable memory (CAM)containing a third plurality of entries, each configured to store an IDfor one stripe in the RAID storage system; wherein the logic isconfigured to identify the at least one entry in the first plurality ofentries by: searching the CAM for the ID matching the receivedoperation, and upon identifying one of the third plurality of entriesbased on the search, identifying the at least one entry in the firstplurality of entries in the first memory using address data outputtedfrom the CAM.
 10. The RAID adapter of claim 9, wherein the first memoryis one of part of the CAM or a separate random access memory (RAM), andwherein the second memory is a RAM.
 11. The RAID adapter of claim 8,wherein the logic is configured to: before determining if the receivedoperation collides with the use-bit vector, determine whether the stripecorresponding to the ID has at least one waiter operation waiting for alock, wherein storing the received operation as the waiter operation isperformed upon determining the stripe has at least one waiter operation,and wherein determining if the received operation collides with theuse-bit vector is performed upon determining the stripe does not haveany waiter operations.
 12. The RAID adapter of claim 11, wherein thelogic is configured to: after determining the stripe has at least onewaiter operation, updating a last waiter link in the at least one entryin the first plurality of entries to point to a location of the at leastone entry in the second plurality of entries containing the waiteroperation.
 13. The RAID adapter of claim 8, wherein the logic isconfigured to: after determining a change in the use-bit vector,determine whether the waiter operation collides with the changed use-bitvector; upon determining that the waiter operation does not collide,remove the at least one entry in the second memory and perform thewaiter operation.
 14. The RAID adapter of claim 8, wherein the logic isconfigured to: upon determining that the received operation does notcollide with the use-bit vector in the at least one entry in the firstplurality of entries, grant the lock to the received operation; andupdate the use-bit vector in the at least one entry to change at leastone bit to indicate that a corresponding block of the stripe is nowlocked by the received operation.
 15. A computer program product formanaging a RAID storage system, the computer program product comprising:a computer-readable storage medium having computer-readable program codeembodied therewith, the computer-readable program code executable by oneor more computer processors to: identify at least one entry in a firstmemory based on an ID associated with a received operation, wherein thefirst memory comprises a first plurality of entries each configured tostore a use-bit vector for a one of a plurality of stripes in the RAIDstorage system, wherein each use-bit vector stores individual bits thateach indicate whether a block of data in one of the stripes is locked byan operation; and upon determining that the received operation collideswith the use-bit vector in the at least one entry in the first memory,store the received operation as a waiter operation in at least one entryin a second memory, wherein the second memory comprises a secondplurality of entries each configured to store information for acorresponding waiter operation that is waiting to obtain a lock for atleast one block of data in one of the stripes.
 16. The computer programproduct of claim 15, wherein identifying the at least one entry in thefirst memory based on the ID further comprises computer-readable programcode further executable to: search a content addressable memory (CAM)for the ID matching the received operation, wherein the CAM comprises athird plurality of entries, each storing an ID for one stripe in theRAID storage system; and upon identifying one of the third plurality ofentries based on the search, identify the at least one entry in thefirst plurality of entries in the first memory using address dataoutputted from the CAM.
 17. The computer program product of claim 15,further comprising computer-readable program code further executable to:before determining if the received operation collides with the use-bitvector, determine whether the stripe corresponding to the ID has atleast one waiter operation waiting for a lock, wherein storing thereceived operation as the waiter operation is performed upon determiningthe stripe has at least one waiter operation, and wherein determining ifthe received operation collides with the use-bit vector is performedupon determining the stripe does not have any waiter operations
 18. Thecomputer program product of claim 17, further comprisingcomputer-readable program code further executable to: after determiningthe stripe has at least one waiter operation, update a last waiter linkin the at least one entry in the first memory to point to a location ofthe at least one entry in the second memory containing the waiteroperation.
 19. The computer program product of claim 17, furthercomprising computer-readable program code further executable to: afterdetermining a change in the use-bit vector, determine whether the waiteroperation collides with the changed use-bit vector; upon determiningthat the waiter operation does not collide, remove the at least oneentry in the second memory and perform the waiter operation.
 20. Thecomputer program product of claim 15, further comprisingcomputer-readable program code further executable to: upon determiningthat the received operation does not collide with the use-bit vector inthe at least one entry in the first plurality of entries, grant the lockto the received operation; and update the use-bit vector in the at leastone entry to change at least one bit to indicate that a correspondingblock of the stripe is now locked by the received operation.